It is useful especially in the field of aeronautics and for aircraft whose information systems are segregated into different security domains, for example in the case of civilian airplanes, AIRBUS A380, A350 airplanes.
In such a context, for example, it is necessary to display active and/or passive messages originating from domains whose security or confidence levels are different on the same screen without segregation of the screen by multiplexing or by other means, partly so that an operator is able to confirm the launching of an action in the more secure domain, while keeping on the screen the messages originating from the less secure domain.
There is reason to do this while reducing the risks of malevolent attacks leading to an erroneous display, especially of passive data, informative data for example, while reducing the amount of data exchanged from the less secure domain toward the more secure domain, and taking into account the ease of use by the simultaneous display of data originating from the two domains.
Also, for reasons of security, the use of a means of segregating the screen into multiple zones, each zone corresponding to the display of messages originating from a domain with different security, by multiplexing for example, is not suitable.
The current technique in aircraft electronics in particular consists of using a display device alternately between the domains to be viewed.
An example of a high-security domain is the architecture of the systems from the domain of aircraft flight.
To process and display parameters of the aircraft flight functions, for example the data on the fuel supply systems, the data on control cutoffs for various aircraft electronics circuits, these systems are linked to a display processing device in the form of a console with a screen and human-machine interface means such as a keyboard, or means for moving and pointing on the screen such as a wheel pointer or a mouse.
The display processing device is able to receive data from the flight-related systems. These data are sent from flight-related embedded systems, and depending on these data the pilots have to take actions that pass through the flight-related systems.
Depending on the actions of the pilots, such as key validation or touch-screen selection from menus, or enabling or disabling systems, the display processing device is able to relay the parameters of the operator actions such as the position of the cursor and pressure on an icon displayed on the screen by the flight-related systems.
The architecture of the flight-related systems is a highly secure architecture that is designed so that no intrusion into the networks of this system that might interfere with operation can be possible.
Because of this, it must not be possible for commands or messages from one domain, for example such as embedded test or maintenance systems like the management system from the maintenance manuals, to be displayed directly at the same time and on the same screen of the display processing device as the messages from the flight-related systems, thus permitting actions on these systems.
The current solution is to switch the display-processing device manually or automatically from one of these domains to the other.
This has the drawback in the case of maintenance in particular of preventing the operator from consulting his electronic manual while he acts on the flight-related systems.
For example, a maintenance operation on the circuit breakers of a system corresponds to a page of the maintenance manual.
When this page is selected, the display processing device is switched to the display of the page of the manual.
If this manual page asks an action to be performed to start or disable the operation of certain circuit breakers, the operator has to switch the display device to the flight-related data display to be able to execute the actions requested.
Doing this, he loses the display of the page of the manual that he was just consulting, which is a problem in terms of risking an error and of ergonomics.
To solve this problem it is then common to have the more secure domain display a confirmation window, possibly with a brief description of the action launched. The launching of the action is then confirmed by the operator using the system.
According to hypothesis No. 1, the confirmation window opened by the more secure domain completely masks the information window displayed by the less secure domain, since it is not possible to segregate the screen or to permit the 2 domains to have access to it simultaneously.
According to hypothesis No. 2, for security reasons, only simple commands will transfer from the less secure domain to the more secure domain. The description and the context of the action launched, information originating from the more secure domain, will accordingly be very succinct, or nonexistent.
Therefore, the problem is that the operator no longer has at his disposal the information originating from the less secure domain when he has to confirm the launching of the action. Now the exact description of the action and its context from which flow its acceptance or refusal to launch the action is written right in the messages originating from the less secure domain.
The problem to be solved is accordingly to preserve the display of data originating from the less secure domain when the display has been switched to the more secure domain to launch actions.
Accordingly, it is necessary to find a means of keeping certain data from the maintenance manual displayed with full security during the display of flight-related data, while preventing any interference by the less secure maintenance domain systems with the more secure systems in the flight-related domain.